Risolvere i problemi relativi allo stack di rete software defined di Windows Server

La presente guida esamina gli errori comuni di SDN (Software Defined Networking) e gli scenari di errore, descrivendo un flusso di lavoro di risoluzione dei problemi che ricorre agli strumenti di diagnostica disponibili. Per ulteriori informazioni su SDN, vedere Software Defined Networking.

Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versioni 21H2 e 20H2

Tipi di errore

L'elenco seguente rappresenta la classe di problemi più spesso riscontrati con Virtualizzazione rete Hyper-V (HNVv1) in Windows Server 2012 R2 dalle distribuzioni di produzione sul mercato. Da numerosi punti di vista, coincide con gli stessi tipi di problemi riscontrati in Windows Server 2016 HNVv2 con il nuovo stack SDN (Software Defined Network).

La maggior parte degli errori può essere classificata in un piccolo set di classi:

• Configurazione non valida o non supportata

  Un utente richiama l'API NorthBound in modo non corretto o con criteri non validi.

• Errore nell'applicazione dei criteri

  I criteri del controller di rete non sono stati recapitati a un host Hyper-V, ritardato o non aggiornato in tutti gli host Hyper-V, ad esempio dopo una migrazione in tempo reale.

• Deviazione della configurazione o bug software

  Problemi relativi al percorso dei dati che causano pacchetti eliminati.

• Errore esterno correlato all'hardware/driver della scheda di interfaccia di rete o all'infrastruttura di rete sottostante

  Offload di attività non correttamente comportate(ad esempio VMQ) o infrastruttura di rete insoded (ad esempio, MTU)Mishaving task offloads (ad esempio VMQ) or underlay network fabric misconfigured (ad esempio MTU)

  La presente guida alla risoluzione dei problemi esamina ciascuna di queste categorie di errori e indica le procedure consigliate e gli strumenti di diagnostica disponibili per identificare e correggere l'errore.

Strumenti di diagnostica

Prima di discutere dei flussi di lavoro per la risoluzione dei problemi per ciascuno di questi tipi di errori, esaminare gli strumenti di diagnostica disponibili.

Per usare gli strumenti di diagnostica controller di rete (percorso di controllo), è necessario prima installare la RSAT-NetworkController funzionalità e importare il NetworkControllerDiagnostics modulo:

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

Per usare gli strumenti di diagnostica HNV (data-path), è necessario importare il modulo HNVDiagnostics:

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

Diagnostica del controller di rete

Questi cmdlet sono documentati in TechNet nel cmdlet Di diagnostica del controller di rete. Consentono di identificare i problemi relativi alla coerenza dei criteri di rete nel percorso di controllo tra i nodi del controller di rete e tra il controller di rete e gli agenti host NC in esecuzione negli host Hyper-V.

I Debug-ServiceFabricNodeStatus cmdlet e Get-NetworkControllerReplica devono essere eseguiti da una delle macchine virtuali del nodo Controller di rete. Tutti gli altri cmdlet di diagnostica NC possono essere eseguiti da qualsiasi host che disponga di connettività al controller di rete e che si trovi nel gruppo di sicurezza di gestione del controller di rete (Kerberos) o che abbia accesso al certificato X.509 per la gestione del controller di rete.

Diagnostica dell'host Hyper-V

Questi cmdlet sono documentati in TechNet nel cmdlet Di diagnostica di virtualizzazione rete Hyper-V (HNV). Consentono di identificare i problemi nel percorso dati tra le macchine virtuali tenant (est/ovest) e il traffico in ingresso attraverso un indirizzo VIP del software di bilanciamento del carico (nord/sud).

Gli Debug-VirtualMachineQueueOperationoggetti , Get-CustomerRoute, Get-ProviderAddressGet-PACAMappingGet-VMNetworkAdapterPortId, , Get-VMSwitchExternalPortId, e Test-EncapOverheadSettings sono tutti i test locali che possono essere eseguiti da qualsiasi host Hyper-V. Gli altri cmdlet richiamano i test del percorso dati tramite il controller di rete e devono quindi accedere al controller di rete, come descritto in precedenza.

GitHub

Il repository GitHub Microsoft/SDN include numerosi script di esempio e flussi di lavoro basati su questi cmdlet predefiniti. In particolare, gli script di diagnostica sono disponibili nella cartella Diagnostica. L'utente può contribuire a questi script inviando richieste pull.

Risoluzione dei problemi relativi a flussi di lavoro e guide

[Hoster] Convalidare l'integrità del sistema

È presente una risorsa incorporata denominata Stato di configurazione in varie risorse del controller di rete. Lo stato di configurazione fornisce informazioni sull'integrità del sistema, inclusa la coerenza tra la configurazione del controller di rete e lo stato effettivo (in esecuzione) negli host Hyper-V.

Per controllare lo stato di configurazione, eseguire il comando seguente da qualsiasi host Hyper-V che dispone di connettività al controller di rete.

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

Di seguito è riportato un messaggio di stato di configurazione di esempio:

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

La tabella seguente mostra l'elenco di codici di errore, di messaggi e di azioni di completamento da eseguire in base allo stato di configurazione osservato.

Codice	Messaggio	Azione
Sconosciuto	Errore sconosciuto
HostUnreachable	Il computer host non è raggiungibile	Controllare la connettività di rete di gestione tra controller di rete e host
PAIpAddressExhausted	Gli indirizzi IP PA esauriti	Aumentare le dimensioni del pool IP della subnet logica del provider HNV
PAMacAddressExhausted	Gli indirizzi Mac PA sono esauriti	Aumentare l'intervallo del pool Mac
PAAddressConfigurationFailure	Impossibile eseguire il plumbing degli indirizzi PA all'host	Controllare la connettività di rete di gestione tra controller di rete e host.
CertificateNotTrusted	Il certificato non è attendibile	Correggere i certificati usati per la comunicazione con l'host.
CertificateNotAuthorized	Certificato non autorizzato	Correggere i certificati usati per la comunicazione con l'host.
PolicyConfigurationFailureOnVfp	Errore durante la configurazione dei criteri VFP	Si tratta di un errore di runtime. Non esiste nessuna soluzione alternativa definita. Raccogliere i log.
PolicyConfigurationFailure	Errore durante il push dei criteri negli host, a causa di errori di comunicazione o di altri errori in NetworkController.	Non esiste nessuna azione definita. Ciò è dovuto a un errore nell'elaborazione dello stato obiettivo nei moduli del Controller di rete. Raccogliere i log.
HostNotConnectedToController	L'host non è ancora connesso al controller di rete	Il profilo di porta non è applicato all'host o l'host non è raggiungibile dal controller di rete. Verificare che la chiave del registro di sistema HostID corrisponda all'ID istanza della risorsa server
MultipleVfpEnabledSwitches	Nell'host sono presenti più commutatori abilitati per VFp	Eliminare uno dei commutatori, poiché l'agente host controller di rete supporta un unico vSwitch con l'estensione VFP abilitata
PolicyConfigurationFailure	Impossibile eseguire il push dei criteri di rete virtuale per una scheda di interfaccia di rete virtuale a causa di errori di certificato o di connettività	Controllare se sono stati distribuiti certificati appropriati (il nome soggetto del certificato deve corrispondere al nome FQDN dell'host). Verificare anche la connettività dell'host con il controller di rete
PolicyConfigurationFailure	Impossibile eseguire il push dei criteri di vSwitch per una VmNic a causa di errori di connettività o di errori di connettività del certificato	Controllare se sono stati distribuiti certificati appropriati (il nome soggetto del certificato deve corrispondere al nome FQDN dell'host). Verificare anche la connettività dell'host con il controller di rete
PolicyConfigurationFailure	Failed to push Firewall policies for a VmNic due to certificate errors or connectivity errors (Impossibile eseguire il push dei criteri del firewall per una VmNic a causa di errori di certificato o di connettività)	Controllare se sono stati distribuiti certificati appropriati (il nome soggetto del certificato deve corrispondere al nome FQDN dell'host). Verificare anche la connettività dell'host con il controller di rete
DistributedRouterConfigurationFailure	Impossibile configurare le impostazioni del router distribuito nella vNic host	Errore dello stack TCPIP. Potrebbe essere necessario pulire le vNIC dell'host PA e DR nel server in cui è stato segnalato questo errore
DhcpAddressAllocationFailure	Allocazione di indirizzi DHCP non riuscita per una VMNic	Controllare se l'attributo indirizzo IP statico è configurato nella risorsa NIC
CertificateNotTrusted CertificateNotAuthorized	Impossibile connettersi a Mux a causa di errori di rete o certificato	Controllare il codice numerico fornito nel codice del messaggio di errore: corrisponde al codice di errore winsock. Gli errori del certificato sono dettagliati (ad esempio, Non è possibile verificare il certificato, Certificato non autorizzato e così via)
HostUnreachable	MUX non integro (il caso comune è BGPRouter disconnesso)	Il peer BGP nella RRAS (macchina virtuale BGP) o nel commutatore Top-of-Rack (ToR) non è raggiungibile o non è possibile eseguire correttamente il peering. Controllare le impostazioni BGP sia nella risorsa Multiplexer del software di bilanciamento del carico che nel peer BGP (ToR o macchina virtuale RRAS)
HostNotConnectedToController	L'agente host del software di bilanciamento del carico non è connesso	Verificare che il servizio agente host del software di bilanciamento del carico sia in esecuzione; fare riferimento ai log dell'agente host del software di bilanciamento del carico (esecuzione automatica) alla ricerca dei possibili motivi, nel caso SLBM (NC) abbia rifiutato il certificato presentato dall'agente host che esegue lo stato verranno visualizzate informazioni sfumate
PortBlocked	La porta VFP è bloccata, a causa della mancanza di criteri VNET/ACL	Controllare se sono presenti altri errori, che potrebbero causare la mancata configurazione dei criteri.
Overloaded	MUX di loadbalancer è sottoposto a overload	Problemi di prestazioni con MUX
RoutePublicationFailure	Loadbalancer MUX non è connesso a un router BGP	Controllare se MUX dispone di connettività con i router BGP e che il peering BGP sia configurato correttamente
VirtualServerUnreachable	Loadbalancer MUX non è connesso al manager del software di bilanciamento del carico	Controllare la connettività tra SLBM e MUX
QosConfigurationFailure	Impossibile configurare i criteri QOS	Verificare se è disponibile una larghezza di banda sufficiente per tutte le macchine virtuali se viene usata la prenotazione QOS

Verificare la connettività di rete tra il controller di rete e l'host Hyper-V (servizio agente host NC)

Eseguire il netstat comando seguente per verificare che siano presenti tre ESTABLISHED connessioni tra l'agente host NC e i nodi del controller di rete e un LISTENING socket nell'host Hyper-V.

• IN ASCOLTO sulla porta TCP:6640 nell'host Hyper-V (servizio agente host NC)
• Due connessioni stabilite dall'IP host Hyper-V sulla porta 6640 all'IP del nodo NC su porte temporanee (> 32000)
• Una sola connessione attiva dall'indirizzo IP dell'host Hyper-V su porta effimera all'indirizzo IP REST del controller di rete sulla porta 6640

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

Controllare i servizi dell'agente host

Il controller di rete comunica con due servizi di agenti host sugli host Hyper-V: agente host SLB e agente host NC. È possibile che uno o entrambi questi servizi non siano in esecuzione. Controllare lo stato e riavviare, se non sono in esecuzione.

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

Controllare l'integrità del controller di rete

Se non sono presenti tre ESTABLISHED connessioni o se il controller di rete non risponde, verificare che tutti i nodi e i moduli di servizio siano operativi usando i cmdlet seguenti.

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

I moduli del servizio del controller di rete sono:

• ControllerService
• ApiService
• SlbManagerService
• ServiceInsertion
• FirewallService
• VSwitchService
• GatewayManager
• FnmService
• HelperService
• UpdateService

Verificare che ReplicaStatus sia Ready e HealthState sia Ok.

In una distribuzione di produzione si usa un controller di rete multinodo, è anche possibile controllare il nodo in cui ogni servizio è primario e il relativo stato di replica singola.

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

Verificare che lo stato della replica sia Pronto per ciascun servizio.

Verificare la presenza di hostID e certificati corrispondenti tra il controller di rete e ogni host Hyper-V

In un host Hyper-V eseguire i cmdlet seguenti per verificare che HostID corrisponda all'ID istanza di una risorsa server nel controller di rete

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties       : Microsoft.Windows.NetworkController.ServerProperties

Correzione

Se si usano script SDNExpress o distribuzione manuale, aggiornare la chiave HostId nel Registro di sistema in modo che corrisponda all'ID istanza della risorsa server. Riavviare l'agente host del controller di rete nell'host Hyper-V (server fisico). Se si usa VMM, eliminare il server Hyper-V da VMM e rimuovere la chiave HostId dal registro di sistema. Aggiungere quindi di nuovo il server tramite VMM.

Verificare che le identificazioni personali dei certificati X.509 utilizzati dall'host Hyper-V (il nome host sarà il nome soggetto del certificato) per la comunicazione (SouthBound) tra l'host Hyper-V (servizio agente host NC) e i nodi controller di rete siano le medesime. Verificare anche che il certificato REST del controller di rete abbia il nome soggetto di CN=<FQDN or IP>.

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

È anche possibile controllare i parametri seguenti di ogni certificato per assicurarsi che il nome del soggetto sia quello previsto (nome host o FQDN REST NC o IP), il certificato non è ancora scaduto e che tutte le autorità di certificazione nella catena di certificati siano incluse nell'autorità radice attendibile.

• Nome soggetto
• Data di scadenza
• Attendibile dall'autorità radice

Se più certificati hanno lo stesso nome soggetto nell'host Hyper-V, l'agente host controller di rete sceglierà in modo casuale uno da presentare al controller di rete. Questo potrebbe non corrispondere all'identificazione personale della risorsa server nota al controller di rete. In questo caso, eliminare uno dei certificati con lo stesso nome soggetto nell'host Hyper-V e quindi riavviare il servizio Agente host del controller di rete. Se non è ancora possibile stabilire una connessione, eliminare l'altro certificato con lo stesso nome soggetto nell'host Hyper-V ed eliminare la risorsa server corrispondente in VMM. Ricreare quindi la risorsa server in VMM, che genererà un nuovo certificato X.509 e lo installerà nell'host Hyper-V.

Controllare lo stato di configurazione del bilanciamento del carico software

Lo stato di configurazione del bilanciamento del carico software può essere determinato come parte dell'output del Debug-NetworkController cmdlet. Questo cmdlet restituisce anche il set corrente di risorse del controller di rete nei file JSON, tutte le configurazioni IP di ogni host Hyper-V (server) e i criteri di rete locali dalle tabelle di database dell'agente host.

Per impostazione predefinita, verranno raccolte altre tracce. Per non raccogliere tracce, aggiungere il -IncludeTraces:$false parametro .

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

Le informazioni sullo stato di configurazione del software di bilanciamento del carico sono disponibili nel file diagnostics-slbstateResults.Json presente in questa directory.

Questo file JSON può essere suddiviso nelle sezioni seguenti:

• Infrastruttura
  • SlbmVips: questa sezione elenca l'indirizzo IP dell'indirizzo VIP del manager del software di bilanciamento del carico, usato dal controller di rete per coordinare la configurazione e l'integrità tra i MUX del software di bilanciamento del carico e gli agenti host del software di bilanciamento del carico.
  • MuxState: questa sezione elenca un valore per ogni Mux del software di bilanciamento del carico distribuito in modo da ottenere lo stato del mux
  • Configurazione del router: questa sezione elenca il numero di sistema autonomo (ASN) del router upstream (BGP Peer), l'indirizzo IP di transito e l'ID. Elencherà anche l'ASN del MUX del software di bilanciamento del carico e l'indirizzo IP di transito.
  • Informazioni sull'host connesso: questa sezione elenca l'indirizzo IP di gestione di tutti gli host Hyper-V disponibili per eseguire carichi di lavoro con carico bilanciato.
  • Intervalli vip: questa sezione elenca gli intervalli di pool di indirizzi IP VIP pubblici e privati. L'indirizzo VIP SLBM verrà incluso come indirizzo IP allocato da uno di questi intervalli.
  • Route Mux: questa sezione elenca un valore per ogni Mux del software di bilanciamento del carico contenente tutti gli annunci di route per quel particolare mux.
• Tenant
  • VipConsolidatedState: questa sezione elenca lo stato di connettività per ogni indirizzo VIP tenant, incluso il prefisso di route annunciato, l'host Hyper-V e gli endpoint DIP.

Convalida del gateway

Dal controller di rete:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

Dalla macchina virtuale del gateway:

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

Dall'interruttore top of rack (ToR):

sh ip bgp summary (for 3rd party BGP Routers)

Router BGP di Windows:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Oltre a questi, dai problemi riscontrati finora (in particolare nelle distribuzioni basate su SDNExpress), il motivo più comune per cui il raggruppamento tenant non viene configurato nelle macchine virtuali GW sembra essere il fatto che la capacità GW in FabricConfig.psd1 è inferiore rispetto a ciò che gli utenti tentano di assegnare alle connessioni di rete (tunnel S2S) in TenantConfig.psd1. Questa operazione può essere verificata facilmente confrontando gli output dei cmdlet seguenti:

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Provider dei servizi di hosting] Convalidare il piano dati

Dopo aver distribuito il controller di rete, aver creato le reti virtuali tenant e le subnet ed aver collegato le macchine virtuali alle subnet virtuali, è possibile eseguire test aggiuntivi a livello di infrastruttura da parte dell'host per controllare la connettività del tenant.

Controllare la connettività di rete logica del provider HNV

Dopo che la prima macchina virtuale guest in esecuzione in un host Hyper-V è stata connessa a una rete virtuale tenant, il controller di rete assegnerà due indirizzi IP del provider HNV (indirizzi IP PA) all'host Hyper-V. Questi indirizzi IP provengono dal pool IP della rete logica del provider HNV e saranno gestiti dal controller di rete. Per scoprire quali sono questi due indirizzi IP HNV:

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

Questi indirizzi IP del provider HNV (IP PA) vengono assegnati alle schede Ethernet create in un raggruppamento di rete TCPIP separato e hanno un nome di scheda VLANX, dove X è la VLAN assegnata alla rete logica del provider HNV (trasporto).

La connettività tra due host Hyper-V tramite la rete logica del provider HNV può essere eseguita da un ping con un parametro aggiuntivo (-c Y), dove Y rappresenta il raggruppamento di rete TCPIP in cui vengono creati i PAhostVNIC. Questo raggruppamento può essere determinato eseguendo:

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

Si supponga, ad esempio, che gli host Hyper-V 1 e 2 abbiano i seguenti indirizzi IP del provider HNV (PA):

Host Hyper-V	Indirizzo IP PA 1	Indirizzo IP PA 2
Host 1	10.10.182.64	10.10.182.65
Host 2	10.10.182.66	10.10.182.67

è possibile effettuare il ping tra i due indirizzi usando il comando seguente per controllare la connettività di rete logica del provider HNV.

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

Correzione

Se il ping del provider HNV non funziona, controllare la connettività di rete fisica, inclusa la configurazione VLAN. Le schede di interfaccia di rete fisiche di ogni host Hyper-V devono essere in modalità trunk, senza una specifica VLAN assegnata. La scheda di interfaccia di rete virtuale dell'host di gestione deve essere isolata nella VLAN della rete logica di gestione.

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

Controllare il supporto di fotogrammi jumbo e MTU nella rete logica del provider HNV

Un altro problema comune nella rete logica del provider HNV è che le porte di rete fisiche e/o la scheda Ethernet non hanno una MTU sufficientemente grande configurata per gestire l'overhead dall'incapsulamento VXLAN (o NVGRE).

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

Per verificare se la rete logica del provider HNV supporta le dimensioni end-to-end di MTU maggiori, usare il Test-LogicalNetworkSupportsJumboPacket cmdlet :

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

Correzione

• Regolare le dimensioni MTU sulle porte del commutatore fisico in modo che siano almeno di 1674B (incluse intestazioni Ethernet da 14B e trailer)
• Se la scheda NIC non supporta la parola chiave EncapOverhead, modificare la parola chiave JumboPacket in modo che sia almeno 1674B

Controllare la connettività della scheda di interfaccia di rete della macchina virtuale del tenant

Ogni scheda di interfaccia di rete della macchina virtuale assegnata a una macchina virtuale guest ha un mapping CA-PA tra l'indirizzo del cliente privato (CA) e lo spazio dell'indirizzo del provider HNV (PA). Questi mapping vengono mantenuti nelle tabelle del server OVSDB in ogni host Hyper-V e sono disponibili eseguendo il cmdlet seguente.

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

Con queste informazioni, è ora possibile avviare un ping della macchina virtuale tenant da Hoster dal controller di rete usando il Test-VirtualNetworkConnection cmdlet .

Scenari di risoluzione dei problemi specifici

Le sezioni seguenti forniscono indicazioni per la risoluzione dei problemi relativi a scenari specifici.

Nessuna connettività di rete tra due macchine virtuali tenant

1. [Tenant] Assicurarsi che Windows Firewall non blocchi il traffico nelle macchine virtuali tenant.
2. [Tenant] Verificare che gli indirizzi IP siano stati assegnati alla macchina virtuale tenant eseguendo ipconfig.
3. [Hoster] Eseguire Test-VirtualNetworkConnection dall'host Hyper-V per convalidare la connettività tra le due macchine virtuali tenant in questione.

Esempio

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

Creare un ping CA tra "Green Web VM 1" con SenderCA IP di 192.168.1.4 nell'host "sa18n30-2.sa18.nttest.microsoft.com" con l'indirizzo IP Mgmt 10.127.132.153 verso l'IP ListenerCA 192.168.1.5 entrambi collegati alla subnet virtuale (VSID) 4114.

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[Tenant] Verificare che nella subnet virtuale o nelle interfacce di rete della macchina virtuale non siano specificati criteri firewall distribuiti che bloccano il traffico.

Eseguire una query sull'API REST del controller di rete disponibile nell'ambiente demo di sa18n30nc nel dominio sa18.nttest.microsoft.com.

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

Esaminare la configurazione IP e le subnet virtuali che fanno riferimento a questo elenco di controllo di accesso

1. [Provider dei servizi di hosting] Eseguire Get-ProviderAddress in entrambi gli host Hyper-V che ospitano le due macchine virtuali tenant in questione e quindi eseguire Test-LogicalNetworkConnection o ping -c <compartment> dall'host Hyper-V per convalidare la connettività nella rete logica del provider HNV
2. [Provider dei servizi di hosting] Assicurarsi che le impostazioni di MTU siano corrette negli host Hyper-V e su qualsiasi dispositivo di commutazione di livello 2 tra gli host Hyper-V. Eseguire Test-EncapOverheadValue in tutti gli host Hyper-V in questione. Verificare inoltre che tutte le opzioni di livello 2 tra abbiano MTU impostato su almeno 1674 byte per tenere conto dell'overhead massimo di 160 byte.
3. [Provider dei servizi di hosting] Se gli indirizzi IP PA non sono presenti e/o la connettività CA è interrotta, verificare che i criteri di rete siano stati ricevuti. Eseguire Get-PACAMapping per verificare se vengono stabilite correttamente le regole di incapsulamento e i mapping CA-PA necessari per la creazione di reti virtuali sovrapposte.
4. [Provider dei servizi di hosting] Verificare che l'agente host del controller di rete sia connesso al controller di rete. A tale scopo, eseguire netstat -anp tcp |findstr 6640.
5. [Provider dei servizi di hosting] Verificare che l'ID host in HKLM/ corrisponda all'ID dell'istanza delle risorse del server che ospitano le macchine virtuali tenant.
6. [Provider dei servizi di hosting] Verificare che l'ID profilo porta corrisponda all'ID istanza delle interfacce di rete della macchina virtuale delle macchine virtuali tenant.

Registrazione, traccia e diagnostica avanzata

Le sezioni seguenti forniscono informazioni su diagnostica avanzata, registrazione e tracing.

Registrazione centralizzata del controller di rete

Il controller di rete può raccogliere automaticamente i log del debugger e archiviarli in una posizione centralizzata. La raccolta di log può essere abilitata quando si distribuisce il controller di rete per la prima volta o in qualsiasi momento successivo. I log vengono raccolti dai controller di rete e dagli elementi di rete gestiti dal controller di rete: computer host, software di bilanciamento del carico (SLB) e computer gateway.

Questi log includono i log di debug per il cluster del controller di rete, l'applicazione del controller di rete, i log del gateway, il software di bilanciamento del carico, la rete virtuale e il firewall distribuito. Ogni volta che viene aggiunto un nuovo host/software di bilanciamento del carico/gateway al controller di rete, la registrazione viene avviata in tali computer. Analogamente, quando un host/software di bilanciamento del carico/gateway viene rimosso dal controller di rete, la registrazione viene arrestata in tali computer.

Abilitazione della registrazione

La registrazione viene abilitata automaticamente quando si installa il cluster controller di rete usando il Install-NetworkControllerCluster cmdlet . Per impostazione predefinita, i log vengono raccolti localmente nei nodi del controller di rete in %systemdrive%\SDNDiagnostics. È consigliabile modificare questo percorso in modo che sia una condivisione file remota (non locale).

I log del cluster del controller di rete vengono archiviati in %programData%\Windows Fabric\log\Traces. È possibile specificare un percorso centralizzato per la raccolta di log con il DiagnosticLogLocation parametro con la raccomandazione che si tratta anche di una condivisione file remota.

Se si vuole limitare l'accesso a questo percorso, è possibile fornire le credenziali di accesso con il LogLocationCredential parametro . Se si specificano le credenziali per accedere al percorso del log, è necessario specificare anche il CredentialEncryptionCertificate parametro , usato per crittografare le credenziali archiviate localmente nei nodi del controller di rete.

Con le impostazioni predefinite, è consigliabile avere almeno 75 GB di spazio libero nella posizione centrale e 25 GB nei nodi locali (se non si usa una posizione centrale) per un cluster controller di rete a tre nodi.

Modificare le impostazioni di registrazione

È possibile modificare le impostazioni di registrazione in qualsiasi momento usando il cmdlet Set-NetworkControllerDiagnostic. È possibile modificare le impostazioni seguenti:

• Percorso del log centralizzato.

  È possibile modificare il percorso in modo da archiviare tutti i log, utilizzando il parametro DiagnosticLogLocation.

• Credenziali per accedere al percorso del log.

  È possibile modificare le credenziali per accedere al percorso del log, utilizzando il parametro LogLocationCredential.

• Passare alla registrazione locale.

  Se è stato specificato un percorso centralizzato per archiviare i log, è possibile tornare alla registrazione in locale nei nodi del controller di rete con il parametro UseLocalLogLocation (non consigliato a causa di requisiti di spazio su disco di grandi dimensioni).

• Ambito di registrazione.

  Per impostazione predefinita, vengono raccolti tutti i log. È possibile modificare l'ambito per raccogliere solo i log del cluster del controller di rete.

• Livello di registrazione.

  Il livello di registrazione predefinito è Informazioni. È possibile modificarlo in Errore, Avviso o Dettagliato.

• Durata del log.

  I log vengono archiviati in modo circolare. Sono disponibili tre giorni di registrazione dei dati per impostazione predefinita, sia che si usi la registrazione locale o quella centralizzata. È possibile modificare questo limite di tempo con il LogTimeLimitInDays parametro .

• Dimensioni della durata del log.

  Per impostazione predefinita, si avrà un massimo di 75 GB di dati di registrazione se si utilizza la registrazione centralizzata e 25 GB se si usa quella locale. È possibile modificare questo limite con il LogSizeLimitInMBs parametro .

Raccolta di log e tracce

Per impostazione predefinita, le distribuzioni VMM usano la registrazione centralizzata per il controller di rete. Il percorso della condivisione file per questi log viene specificato durante la distribuzione del modello di servizio del controller di rete.

Se non è stato specificato un percorso di file, la registrazione locale verrà usata in ogni nodo del controller di rete con i log salvati in C:\Windows\tracing\SDNDiagnostics. Questi log vengono salvati usando la gerarchia seguente:

• CrashDumps
• NCApplicationCrashDumps
• NCApplicationLogs
• PerfCounters
• SDNDiagnostics
• Tracce

Il controller di rete utilizza Service Fabric (Azure). I log di Service Fabric potrebbero essere necessari per la risoluzione di determinati problemi. Questi log sono disponibili in ogni nodo controller di rete in C:\ProgramData\Microsoft\Service Fabric.

Se un utente ha eseguito il Debug-NetworkController cmdlet, saranno disponibili altri log in ogni host Hyper-V, specificato con una risorsa server nel controller di rete. Questi log (e le tracce, se abilitati) vengono mantenuti in C:\NCDiagnostics.

Diagnostica SLB

Errori dell'infrastruttura SLBM (azioni del provider di servizi di hosting)

1. Verificare che SLBM funzioni e che i livelli di orchestrazione possano comunicare tra loro: SLBM -> SLB Mux and SLBM -> SLB Host Agents. Eseguire DumpSlbRestState da qualsiasi nodo con accesso all'endpoint REST del controller di rete.
2. Convalidare SDNSLBMPerfCounters in PerfMon in una delle macchine virtuali del nodo del controller di rete (preferibilmente il nodo del controller di rete primario - Get-NetworkControllerReplica):
   1. Il motore del bilanciamento del carico (LB) è connesso a SLBM? (SLBM LBEngine Configurations Total > 0)
   2. SBM conosce almeno i propri endpoint? (VIP Endpoints Total>= 2)
   3. Gli host Hyper-V (DIP) sono connessi a SLBM? (HP clients connected == num servers)
   4. SLBM è connesso a Mux? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VMs).
3. Verificare che il router BGP configurato sia stato eseguito correttamente il peering con il MUX SLB.
   1. Se si usa RRAS con accesso remoto (ovvero, macchina virtuale BGP):
      1. Get-BgpPeer dovrebbe essere connesso.
      2. Get-BgpRouteInformation dovrebbe mostrare almeno una route per l'indirizzo VIP self-SLBM.
   2. Se si usa il commutatore Top-of-Rack (ToR) fisico come peer BGP, consultare la documentazione:
      1. Ad esempio: # show bgp instance
4. Convalidare i contatori SlbMuxPerfCounters e SLBMUX in PerfMon nella macchina virtuale Mux SLB.
5. Controllare lo stato di configurazione e gli intervalli VIP nella risorsa di Gestione bilanciamento del carico software.
   1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (controllare gli intervalli VIP nei pool IP e assicurarsi che l'indirizzo VIP self-VIP slBM (LoadBalanacerManagerIPAddress) e tutti gli indirizzi VIP rivolti al tenant si trovino all'interno di questi intervalli)
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
   2. Debug-NetworkControllerConfigurationState -

Se uno dei controlli precedenti ha esito negativo, anche lo stato del software di bilanciamento del carico del tenant sarà in modalità di errore.

Correzione

In base alle informazioni di diagnostica seguenti presentate, correggere quanto segue:

• Verificare che i multiplexer SLB siano connessi
  • Risolvere i problemi relativi al certificato
  • Correggere i problemi di connettività di rete
• Verificare che le informazioni sul peering BGP siano configurate correttamente
• Verificare che l'ID host nel registro di sistema corrisponda all'ID istanza del server nella risorsa server (fare riferimento all'appendice per il codice errore HostNotConnected)
• Raccogliere i log

Errori del tenant SLBM (provider di servizi di hosting e azioni del tenant)

1. [Hoster] Verificare Debug-NetworkControllerConfigurationState se le risorse loadBalancer sono in uno stato di errore. Provare a mitigare seguendo la tabella Attività presente nell'Appendice.
   1. Verificare che un endpoint VIP sia presente e che le route pubblicitarie siano visualizzate.
   2. Controllare il numero di endpoint DIP individuati per l'endpoint VIP.
2. [Tenant] Verificare che le risorse di Load Balancer siano specificate correttamente.
   1. Convalidare gli endpoint DIP registrati in SLBM ospitano macchine virtuali tenant, che corrispondono alle configurazioni IP del pool di indirizzi back-end di LoadBalancer.
3. [Provider di servizi di hosting] Se gli endpoint DIP non vengono individuati o connessi:

   1. Controllare Debug-NetworkControllerConfigurationState

      Verificare che il controller di rete e l'agente host SLB siano connessi correttamente al coordinatore eventi del controller di rete tramite netstat -anp tcp |findstr 6640).

   2. Archiviare HostIdla chiave regkey del servizio (codice di errore di riferimento HostNotConnected nell'Appendice) corrisponde all'ID istanza della risorsa server corrispondente (Get-NCServer |convertto-json -depth 8).nchostagent

   3. Controllare l'ID del profilo di porta per verificare che la porta della macchina virtuale corrisponda all'ID istanza della risorsa della scheda di interfaccia di rete della macchina virtuale corrispondente.

4. [Provider di hosting] Raccogliere i log.

Traccia mux SLB

Le informazioni dei mux del software di bilanciamento del carico possono essere determinate anche tramite il Visualizzatore eventi.

1. Selezionare Mostra log analitici e di debug nel menu Visualizza Visualizzatore eventi.
2. Passare a Registri applicazioni e servizi di>Microsoft>Windows>SlbMuxDriver>trace in Visualizzatore eventi.
3. Fare clic con il pulsante destro del mouse su di esso e selezionare Abilita log.

Traccia VFP e vSwitch

Da qualsiasi host Hyper-V che ospita una macchina virtuale guest collegata a una rete virtuale tenant, è possibile raccogliere una traccia VFP per determinare dove possono trovarsi i problemi.

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes